With continuing progress in Ethernet techniques, operators can provide various services by using Ethernet techniques directly within Metropolitan Area Network (MAN). In the meantime, triple play services also drive Ethernet to evolve into carrier Ethernet with higher reliability. During this process, a problem arises as how Ethernet interworks with other networks. The conventional networking way of interconnecting Frame Relay and Ethernet is to carry Ethernet over Frame Relay, so as to provide Local Area Network (LAN) emulation. During the process in which Ethernet gradually evolves into the core of MAN, it is necessary to connect Frame Relay networks to Ethernet, so as to provide Frame Relay emulation.
Services carried over Frame Relay generally use Q.922 protocol, i.e., the Frame Relay Link Access Procedure for Frame (LAPF) protocol. The frame structure for transmission over the Frame Relay data link layer is shown in FIG. 1. Each frame includes 4 fields: Flag Sequence, Address, Information, and Frame Check Sequence (FCS).
The Flag Sequence (F) field is a special 8-bit octet 01111110. Since the length of a Frame Relay frame is variable, this field is used to indicate the beginning and end of a frame. In a received frame, other fields are not allowed to contain content same as that of the Flag Sequence field. Therefore, zero padding is usually used at the transmitting side to prevent 01111110 from occurring in other fields. Inverse processing is performed at the receiving side, i.e., removing the zero bits padded.
The Information field includes user data, the length of which has to be an integer number of bytes, with the maximum default length being 262 bytes. The length of the Information field which the network determines through negotiation is at least 1600 bytes.
Frame Check Sequence (FCS) is the Frame Check Sequence field.
The Address field may have a length of 2-4 bytes, as shown in FIG. 2 and FIG. 3. As illustrated, the Extended Address (EA) includes extended bits for the Address field, and EA=1 indicates that the current byte is the final byte of the Address field.
The Command/Response (C/R) bit is used to identify whether the frame is a command frame or a response frame.
The Data Link Connection Identifier (DLCI) is used to identify a virtual connection carried over the User to Network Interface (UNI) or Network to Network Interface (NNI). The length is 10 bits by default, and may be extended to 16 or 23 bits with EA.
The Discard Eligibility Identifier (DE) Bit: DE=1 indicates that discarding may be considered when congestion occurs in the network.
Forward Explicit Congestion Notification (FECN) is used to notify the user to initiate a congestion avoidance program. FECN=1 indicates the congestion in a direction same as which the FECN indication frame is carried in.
Backward Explicit Congestion Notification (BECN) is used to notify the user to initiate a congestion avoidance program. BECN=1 indicates the congestion in a direction opposite to which the BECN indication frame is carried in.
FIG. 4 is a diagram illustrating the format of 802.1 Ethernet frame. It includes Destination Address (DA), Source Address (SA), frame Length (LEN), Payload TYPE (TYPE), Frame Check Sequence (FCS), Ethernet Customer bridge network TAG (C-TAG), metropolitan Ethernet Service instance TAG (S-TAG), and backbone Ethernet service Instance TAG (I-TAG). For specific descriptions about each of the fields, please refer to the IEEE 802.1d, IEEE 802.1q, and IEEE 802.1ah protocol documents.
As shown in FIG. 4, in the 4-byte C-TAG, there are a 2-byte Protocol Type ID (TPID) and a 2-byte virtual local area network Tag Control Information (TCI). In the 6-byte I-TAG, there are a 2-byte TPDI and a 3-byte backbone Ethernet service Instance Service Identifier (I-SID).
PWE 3 working group of the IETF standardization organization is dedicated to researches on various end-to-end pseudo wire emulations over Packet Switched Network (PSN). The emulated services may be transmitted by means of Frame Relay, Ethernet, ATM, TDM dedicated lines. PWE3 uses the tunnel mechanism on PSN to emulate the basic properties of a certain service. The tunnel is referred to as Pseudo Wire (PW) here. PWE3 encapsulates the Protocol Data Unit (PDU) for a certain service, where the PDU contains data and control information needed by certain services. With the PWE3 mechanism, operators may transfer all transportation services into a converged network (such as IP/MPLS).
A general PWE3 encapsulation typically includes four parts: the header for the Packet Switch Network (PSN), the Pseudo Wire Identifier, the Control Word and the PDU. FIG. 5a shows the encapsulation format for Frame Relay over Multi-Protocol Log Switch (MPLS). FIG. 5b and FIG. 5c show the control word formats for one-to-one mapping and multiple-to-one mapping, respectively. For a different mapping, the control word and the payload may vary. As shown in FIG. 5b, for one-to-one mapping, one pseudo wire carries only one virtual circuit. Accordingly, the DLCI in the address field, which is valid only in the local Frame Relay circuit, becomes invalid when a re-encapsulation is performed at the peer side. Therefore, the payload uses only the information field of the encapsulated Frame Relay, and it is not necessary to encapsulate the address field. F, B, D, and C are obtained by coping directly from the BECN, FECN, DE and C/R in the address field of the Frame Relay. As shown in FIG. 5c, for multiple-to-one mapping, one pseudo wire may carry a plurality of Frame Relay virtual circuits, thus the payload includes the information field and address field of the Frame Relay frame. LEN and SN represent the length and the sequence number for the packet, respectively. Furthermore, since the maximum packet length may be up to 65535 bytes, it is not necessary to divide the Frame Relay frame.
The PWE3 encapsulation of the PWE3 working group has a disadvantage in that its object is limited to IP or MPLS based Packet Switch Networks.
Furthermore, there are two kinds of interworking between different kinds of networks: network interworking and service interworking. In network interworking, two terminals use the same protocol, but different protocols are used between networks, and the existence of the network at the central position is transparent to the users at both ends. In service interworking, different protocols may be used by different terminals, and a peer-to-peer communication is performed between them.
A related art discloses a service interworking between Ethernet and Frame Relay networks, and the corresponding network model is shown in FIG. 6(1) and FIG. 6(2). This interworking is based on upper layer protocols. The network model for service interworking between the Ethernet and Frame Relay networks is shown in FIG. 6(1) and FIG. 6(2). This interworking technique is based on upper layer protocols. For example, if the upper protocol carried over the Frame Relay network is IP protocol, an Interworking Function (IWF) in a direction from Ethernet to Frame Relay separates an IP message from a Frame Relay frame, and encapsulates it into an Ethernet frame; an IWF in a direction from Frame Relay to Ethernet separates the IP message from the Ethernet frame and encapsulates it into a Frame Relay frame. But this technique has a disadvantage in that the final implementation depends on conversions between messages for different layers in the Open System Interconnection (OSI) reference model since the interconnection of two networks is implemented on the basis of service interworking. In other words, in order to separate/encapsulate upper layer protocol messages from/into Frame Relay or Ethernet frames, it is necessary for the interworking function to have knowledge of the frame format of L2 Frame Relay and Ethernet frames, as well as the type of upper protocols, which leads to very complicated implementations.